Reports of 32 Clear search Modify search
AdV-COM (AdV commissioning (1st part) )
michimura, swinkels - 19:35 Thursday 09 August 2018 (42387) Print this report
Drum mode tracking using B1p

The drum mode frequency shift at the time constant of ~1000 sec after reaching dark fringe was clearly seen using B1p.
This thermal transient should be related to thermal lensing, and 56 MHz sideband build-up also has similar decay time constant.


Off-line drum mode tracking of B1p and B1:
We had a look at the frequency shift of the drum modes during this weekend's commissioning run. To capture the thermal transient as early as possible after the arrival at dark fringe, we looked at B1p_PD1_Blended, for which the shutter is now opened directly after arrival at dark fringe.

Since the online drum-mode tracker was still using B1_DC_PD2, we tracked the drum modes off-line using the new line tracker described in VIR-0420A-18. Best results are obtained with a window length of 1000 seconds, which gives a frequency resolution of 1 mHz and a temporal one of 500 seconds.

Fig 1 and Fig 2 compare the spectrograms of the NI drum mode seen in respectively SDB2_B1_PD2_Audio and SDB2_B1p_PD1_Blended. The improvement is not huge, but with B1p we do get about 2 earlier data points for every lock acquisition. Apart from the slow transients, you can barely notice a faster one just after arriving at dark fringe. Note that we can not do any better given the usual trade-offs between frequency and temporal resolution.


Thermal transient at ~1000 sec:
We also compared the off-line line tracker outputs from B1p with ring heater temperatures.

Fig 3 shows the ring heater temperature and the drum mode frequency calibrated into ring heater temperature, for NI and WI. We can see that the drum mode temperature agrees well with the ring heater temperature. But there is a faster temperature transient, which drum mode sees but not the ring heater. From exponential fitting (a*exp(t/tau)+c) of the temperature difference between the drum mode temperature and ring heater temperature, we can see that it has a time constant of ~1000 sec.

Fig 3 also plots the 56 MHz sideband power build up (LSC_B4_112MHz_MAG). From exponential fitting, we can see that it also has a time constant of ~1000 sec. For the fitting, a*exp(t/tau)+c+x*d was used here to compensate for slow drift. On a side note, the time constant when we were at 13 W was also similar (logbook #41817).

We can also kind of somewhat see that NI drum mode temperature has larger transient than WI. This might be related to NI having larger absorption than WI (0.6 ppm for NI, 0.36 ppm for WI, according to VIR-0566A-18).


On-line line tracker reverted to B1 version:
I originally thought it might be possible to see even quicker thermal transient when reaching the dark fringe using the on-line line tracker to look into the power drop at dark fringe issue (see logbook #42348). However, as already mentioned, frequency resolution and temporal resolution was not enough since the on-line line tracker uses a window length of 100 seconds. The power drop at DF has a time constant of ~50 sec (logbook #42272).
So, we reverted it to B1 version.

Images attached to this report
AdV-ISC (Parametric instabilities)
michimura - 18:38 Wednesday 08 August 2018 (42370) Print this report
Comment to Mirror mode identification with temp change (41794)

Using the ring heater temperatures and line frequencies from the line tracker, the arm mirror modes upto 15kHz are identified.
For modes with higher frequencies, it was hard to identify from this method.

Summary:
[Drum modes around 7.807kHz (time series plot, temperature vs line frequency plot, B1 spectrum)]
PAY_DRUM1_FREQ: NI 0.878 Hz/K
PAY_DRUM2_FREQ: WI 0.871 Hz/K
PAY_DRUM3_FREQ: currently no line in the band
PAY_DRUM4_FREQ: lower frequency is from WE 0.882 Hz/K, upper frequency from NE 0.676 Hz/K?

[Modes around 10.107kHz (time series plot, temperature vs line frequency plot, B1 spectrum)]
PAY_10kHz1_FREQ: NI 1.074 Hz/K
PAY_10kHz2_FREQ: WI 1.083 Hz/K
PAY_10kHz3_FREQ: currently no line in the band
PAY_10kHz4_FREQ: lower frequency is from WE 1.057 Hz/K, upper frequency from NE 0.842 Hz/K?

[Modes around 15.007kHz (time series plot, temperature vs line frequency plot, B1 spectrum)]
PAY_15kHz1_FREQ: NI? 1.584 Hz/K?
PAY_15kHz2_FREQ: NE? 1.109 Hz/K?
PAY_15kHz3_FREQ: WE 1.720 Hz/K
PAY_15kHz4_FREQ: WI? 1.357 Hz/K?
PAY_15kHz5_FREQ: unclear

[Modes around 26.2kHz (time series plot, temperature vs line frequency plot, B1 spectrum)]
PAY_26kHz1_FREQ: WE? 2.033 Hz/K
PAY_26kHz2_FREQ: unclear
PAY_26kHz3_FREQ: WE? 2.021 Hz/K

[Modes around 9.67-8kHz (time series plot 1-4 5-8, temperature vs line frequency plot 1-4 5-8, B1 spectrum)]
PAY_9pt6kHz1_FREQ: WI 0.849 Hz/K
PAY_9pt6kHz2_FREQ: NI 0.840 Hz/K
PAY_9pt6kHz3_FREQ: WI (noisy)
PAY_9pt6kHz4_FREQ: NI (noisy)
PAY_9pt6kHz5_FREQ: NE 0.629 Hz/K? (line moves to 9pt6kHz6)
PAY_9pt6kHz6_FREQ: lower frequency from NE 0.778 Hz/K?, upper frequency from WE 0.831 Hz/K
PAY_9pt6kHz7_FREQ: NE, but basically no line in the band (line moves to 9pt6kHz8)
PAY_9pt6kHz8_FREQ: lower frequency from NE, upper frequency from WE (noisy)

[Modes around 39.2-3kHz (time series plot 1-4 5-8, temperature vs line frequency plot 1-4 5-8, B1 spectrum)]
PAY_39kHz1_FREQ: unclear
PAY_39kHz2_FREQ: unclear
PAY_39kHz3_FREQ: WE 3.635 Hz/K?
PAY_39kHz4_FREQ: unclear
PAY_39kHz5_FREQ: currently no line in the band
PAY_39kHz6_FREQ: WI 3.208 Hz/K
PAY_39kHz7_FREQ: WE 3.291 Hz/K
PAY_39kHz8_FREQ: WI? 3.742 Hz/K

[Modes around 43.9-44.1kHz (time series plot, temperature vs line frequency plot, B1 spectrum)]
PAY_44kHz1_FREQ: unclear
PAY_44kHz2_FREQ: unclear
PAY_44kHz3_FREQ: WI? 3.633 Hz/K?
PAY_44kHz4_FREQ: unclear
PAY_44kHz5_FREQ: currently no line in the band
PAY_44kHz6_FREQ: unclear

Dots in different colors indicate data from different locks.


Method:
I did a similar analysis done a year ago by Bas (logbook #39039), using 4 days of data during the commissioning run in Aug 2-5. Data in LOW_NOISE_3 is used.

1. Make temperature vs line frequency plots using ring heater temperatures (INF_TCS_NI_RH_TE, INF_TCS_WI_RH_TE, ENV_TCS_NE_RH_TE, ENV_TCS_WE_RH_TE) and line tracker frequency outputs (PAY_{mode}_FREQ).

2. Calculated correlation coefficients and linear fitted to get the temperature dependence. Used these information to identify the mirror.

3. For line tracker frequency output channels tracking two modes, I splitted the data into two using moving average using the time window of 3000 seconds. Lower frequency output is labeled with the suffix _lower, and upper frequency output is labeled with the suffix _upper.


Result:
[Drum modes around 7.807kHz]
From correlation coefficients, we can clearly see that DRUM1 is from NI and DRUM2 is from WI.
DRUM3 is now tracking nothing, and DRUM4 is tracking two modes. Lower frequency of DRUM4 can be identified to be WE from the correlation coefficient.
Upper frequency of DRUM4 is therefore NE.
These results are consistent with previous studies (logbook #41935, #41794 (this figure) and VIR-0505A-18).
The temperature dependance of drum mode frequencies is ~0.88 Hz/K, which is consistent with previous studies (logbook #39039, #41798).

[Modes around 10.107kHz]
Modes can be identified similarly with drum modes.
These results are consistent with previous studies  (logbook #41794 (this figure) and VIR-0505A-18).
The temperature dependance of mode frequencies is ~1.07 Hz/K.

[Modes around 15.007kHz]
For these modes, some of the lines moved from one channel to different channel, so I only used the first half (~ 2 days) of the data.
15kHz3 can be clearly identified to be WE and is consistent with logbook #41794 (this figure).
Others are quite unclear, but considering the combination of high correlation coefficients and temperature dependance close to 1.7 Hz/K obtained from WE, 15kHz1, 15kHz2 and 15kHz4 are likely to be from NI, NE and WI respectively.

[Modes around 26.2kHz]
For these modes, the line at 26kHz2 moved out from the frequency region, so I only used the first half (~ 2 days) of the data.
Both 26kHz1 and 26kHz3 has high correlation with WE temperature, as already found in logbook #41794 (this figure).
They might not be from mirror modes, but something from WE.

[Modes around 9.6kHz]
These modes are tricky (they were also quiet during the weekend).
From study in logbook #41794 (this figure), we can see that 9pt6kHz6 and 9pt6kHz8 are from WE. There are 4 groups but they do not correspond to 4 mirrors and groups are mixed.
From correlation coefficients, we can clearly see that 9pt6kHz1 is from WI and 9pt6kHz2 is from NI.
Therefore, we can guess that 9pt6kHz3 and 9pt6kHz4 are also from WI and NI, respectively, although these channels are noisy due to small amplitude during the weekend. For fitting the data of these channels, I only used the data which has not too large fluctuation from the trend we can see by our eye (data used is indicated with black dots).
The rest is 9pt6kHz5 and 9pt6kHz7 and they are from NE. 9pt6kHz7 is currently out of band and NE mode is actually tracked by 9pt6kHz8. Also, NE line in 9pt6kHz5 moved to 9pt6kHz6 during the weekend.
We can also confirm that all the temperature dependances of mode frequencies are ~0.84 Hz/K.

[Modes around 39.2-3kHz]
These modes were quiet and unclear.
From study in logbook #41794 (this figure and this figure), we can see that 39kHz3 and 39kHz7 are from WE, and correlation coefficients support this.
We can also see that 39kHz6 and 39kHz8 have high coherence with WI temperature and similar temperature dependance (~3.2-3.7 Hz/K).
For 39kHz1, it was noisy and unclear.
For 29kHz2, correlation coefficients are similar for each mirror and unclear.
For 39kHz4, the line moved away from the band and we don't have much data.
If you look at the B1 spectrum, we see peak at 39306 Hz, which is not tracked by the line tracker. No line in 39kHz5 band.
We might have to check these modes and line tracker bands again when these modes are excited.

[Modes around 43.9-44.1kHz]
For these modes, no plot is in logbook #41794. So, I made one here.
As you can see, no peaks in this line tracker frequency band moved during large temperature change in WE in June 10.
44kHz3 has high correlation with WI temperature, so it might be from WI, but others are unclear.
May be we should look into these modes again.

Images attached to this comment
Optical characterization (Optical characterization)
michimura - 15:32 Monday 06 August 2018 (42348) Print this report
Comment to Where is the power lost? (42058)

The line tracker code was temporarily modified to use SDB2_B1p_PD1_Blended instead of SDB2_B1_PD2_Audio_100k at 13:04 UTC today.

B1p is available even if OMCs are not locked, so hopefully we can monitor the mirror temperature transient when reaching the dark fringe and study the power drop at DF (see logbook #42273 and #42314).
B1p_PD1_Blended is 20kHz sampled, so I had to delete line tracker channels above 10 kHz.
Channels currently available are _FREQ and _AMPL of

V1:PAY_{MIR}_VIOLIN# (MIR=NE,NI,WE,WI, #=1-8)
V1:PAY_BS_BUTTERFLY
V1:PAY_BS_DRUM

V1:PAY_DRUM# (#=1-4; 1 is for NI and 2 is for WI according to VIR-0505A-18)
V1:PAY_9pt6kHz# (#=1-8)

The original B1 version (see logbook #41883) is committed to SVN at revision 74203 and B1p version is committed to SVN at revision 74204.
They are also copied as algo_B1.py and algo_B1p.py in /virgoDev/Automation/PyALP/PySpectral directory for easy swap.

AdV-ISC (Subsystem management)
michimura, carbognani - 14:36 Monday 06 August 2018 (42345) Print this report
Comment to PyQt graphical user interfaces for ISC (42150)

Series of PyQt ISC GUIs have been packaged as PyIscGui and the first version has been uploaded in /virgoApp/PyIscGui/v1r0/

This version has also been added under the IceWM menu ISC section and ISC Lancher GUI can be started from there (see attached). ISC Launcher now can launch the following GUIs

- ITF Monitor (logbook #42150)
- LSC Overview (logbook #42150)
- ASC Overview (logbook #42150)
- ISC Photodiodes (logbook #42186)
- ISC Quadrants (logbook #42280)
- Violing Damping (logbook #42344)

Previous Tkinter version of violinUI in SUS section has been removed from IceWM (see, also, logbook #41997).

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
michimura - 14:07 Monday 06 August 2018 (42344) Print this report
Comment to Violin mode damping (41922)

I made a PyQt version of GUI for violing damping.
Previously, the GUI was made with Python Tkinter and current values are acquired using AclParamGet commants.
PyQt version uses ConnectOnline function to continuously get the current values (see logbook #42150 and comments).

PyQt version has almost the same functionality as before, but better since you can monitor the current values live and easier to understand the signal flow.
To save which filters are used and to save whether TX or TY is used, I added the following lines to LSC_SMS.cfg (this is the reason I had to restart LSC Acl; see logbook #42298).

ACL_SMS        "LSC_"        NI_VIOLIN1_ERR    NI_VIOLIN2_ERR    NI_VIOLIN3_ERR    NI_VIOLIN4_ERR    NI_VIOLIN5_ERR    NI_VIOLIN6_ERR    NI_VIOLIN7_ERR    NI_VIOLIN8_ERR
ACL_SMS        "LSC_"        NE_VIOLIN1_ERR    NE_VIOLIN2_ERR    NE_VIOLIN3_ERR    NE_VIOLIN4_ERR    NE_VIOLIN5_ERR    NE_VIOLIN6_ERR    NE_VIOLIN7_ERR    NE_VIOLIN8_ERR
ACL_SMS        "LSC_"        WI_VIOLIN1_ERR    WI_VIOLIN2_ERR    WI_VIOLIN3_ERR    WI_VIOLIN4_ERR    WI_VIOLIN5_ERR    WI_VIOLIN6_ERR    WI_VIOLIN7_ERR    WI_VIOLIN8_ERR
ACL_SMS        "LSC_"        WE_VIOLIN1_ERR    WE_VIOLIN2_ERR    WE_VIOLIN3_ERR    WE_VIOLIN4_ERR    WE_VIOLIN5_ERR    WE_VIOLIN6_ERR    WE_VIOLIN7_ERR    WE_VIOLIN8_ERR
ACL_SMS        "LSC_"        ASC_NI_TX_NOISE_CORR    ASC_NE_TX_NOISE_CORR    ASC_WI_TX_NOISE_CORR    ASC_WE_TX_NOISE_CORR
ACL_SMS        "LSC_"        ASC_NI_TY_NOISE_CORR    ASC_NE_TY_NOISE_CORR    ASC_WI_TY_NOISE_CORR    ASC_WE_TY_NOISE_CORR


"Restore Defaults" button on the top right will restore saved values of GAINs and filters and applies them.
Attached figure shows the current default GAINs and filters which were used in June 22 (at 13W; logbook #41949).

Images attached to this comment
AdV-ISC (Subsystem management)
michimura - 17:12 Wednesday 01 August 2018 (42280) Print this report
Comment to PyQt graphical user interfaces for ISC (42150)

I made a GUI for ISC quadrants, which can be used to monitor DC and RF signals, and to tune demodulation phases (see ISCquadrants.png).
The latest stable version live in /virgoDev/PyIscGui/.
You can open the GUI by

> python ISCquadrants.py


Details:
 - For quadrants, there are _phi0 channels to rotate I and Q both in the suspended bench and ASC.

 - "datadisplay" buttons show the data display which can be used to tune demodulation phases. The configuraton file for the data display live in /olusers/virgorun/ISC/dataDisplay. "datadisplay 1" for QD1 and "datadisplay 2" for QD2.

 - Some of _phi0 channels in ASC were not stored, so I added the following channels in the last line ACL_DAQ_FILTER (line 511) in ASC_Acl.cfg.

B1p_QD1_H_56MHz_phi0    B1p_QD1_V_56MHz_phi0    B1p_QD2_H_56MHz_phi0    B1p_QD2_V_56MHz_phi0
B4_QD1_H_56MHz_phi0    B4_QD1_V_56MHz_phi0    B4_QD2_H_56MHz_phi0    B4_QD2_V_56MHz_phi0
B2_QD1_H_8MHz_phi0    B2_QD1_V_8MHz_phi0


 - Channels for quadrants are made symmetric and it was very easy to make a GUI yes.

 - Currently, B1p QD2 56MHz, B2 QD2 8MHz, B5 QD2 56MHz, B5 QD2 norm, B5 QD2 56MHz are used (see ASC sensing matrix). There are no ASC channels for B2 6MHz and B5 6MHz.


Some updates:
 - Now the launcher screen for ISC is available (Launcher.py; see Launcher.png).
 - Now you can shrink the screens and they will be scrollable (something like this).

Images attached to this comment
Optical characterization (Optical characterization)
michimura, allocca, chiummo - 11:59 Wednesday 01 August 2018 (42272) Print this report
Comment to Where is the power lost? (42058)

To have more statistics on this power drop at DF issue, I fitted the decay curves of photodiode signals.
In June, we had the time constant of ~90 sec, but from July, we have the different time constant of ~50 sec.
The power drop in June was ~10 %, and in June was ~30% (as already reported in logbook #42058).
Time constant being different adds another mystery.....


Method:
1. Get the data of META_ITF_State, B2_DC, B4_DC, B5_DC, B7_DC, B8_DC, B4_12MHz, and B4_112MHz. Extract the lock which reached Low Noise 3, and plotted the data from -100 sec to +1000sec from the point we reached LOCKED_PRITF_DF.

2. Fitted decay curves with a*exp(x/tau)+c for each lock. For DC signals, I used the data from LOCKED_PRITF_DF for 400 sec. For B4_12MHz, I used the data from 50 sec after LOCKED_PRITF_DF for 300 sec since it fluctuates too much at the beginning of DF.

3. Plotted tau and the power drop ratio r=a/c for each lock, and calculated the median (not average since B4_12MHz fluctuates a lot and fitting is not reliable in many cases) and standard deviation.


Result:
The time series data of 34 locks between June 21 to 25 is shown in DFpowerdrop_LOCKED_PRITF_DF_1213574418_432000.png.
The time series data of 13 locks between June 23 to 27 is shown in DFpowerdrop_LOCKED_PRITF_DF_1213574418_432000.png.
Fitted curves are also plotted as dashed black lines. As you can see, the power drop is consistent between locks (semilar plot for B7_DC also in logbook #42225).
In June from June 21, 6 MHz was not decreased in DF (logbook #41932), so we can clearly see that B4 12 MHz also drops (as also reported in logbook #42011).
Note that B4 112 MHz do not decay at this time scale, but it also decays at longer the time constant of 1.5e3 sec (see logbook #41817).
In July, we decreased 6MHz in DF (logbook #42162), so it is hard to tell what's happening for 6 MHz sidebands.

Summary of fitting results are shown below.

From June 21 for 5 days, median of 34 locks (DFpowerdrop_LOCKED_PRITF_DF_1213574418_432000_fitresult.png)
LSC_B2_DC_mean tau=80.17 +/- 60.95 sec
LSC_B2_DC_mean r=35.02 +/- 6.75 %
LSC_B4_DC_mean tau=90.79 +/- 17.83 sec
LSC_B4_DC_mean r=9.79 +/- 0.99 %
LSC_B5_DC_mean tau=87.60 +/- 18.27 sec
LSC_B5_DC_mean r=9.95 +/- 0.90 %
LSC_B7_DC_mean tau=92.40 +/- 18.69 sec
LSC_B7_DC_mean r=9.69 +/- 0.89 %
LSC_B8_DC_mean tau=91.49 +/- 24.35 sec
LSC_B8_DC_mean r=9.48 +/- 0.97 %
LSC_B4_12MHz_MAG_mean tau=108.22 +/- 260.09 sec
LSC_B4_12MHz_MAG_mean r=39.68 +/- 152.40 %


From July for 5 days,  median of 13 locks (DFpowerdrop_LOCKED_PRITF_DF_1213574418_432000_fitresult.png)
LSC_B2_DC_mean tau=114.08 +/- 42.69 sec
LSC_B2_DC_mean r=24.61 +/- 6.15 %
LSC_B4_DC_mean tau=111.69 +/- 615.54 sec
LSC_B4_DC_mean r=7.28 +/- 4.59 %
LSC_B5_DC_mean tau=109.63 +/- 61.33 sec
LSC_B5_DC_mean r=7.45 +/- 2.11 %
LSC_B7_DC_mean tau=115.32 +/- 85.67 sec
LSC_B7_DC_mean r=6.73 +/- 2.53 %
LSC_B8_DC_mean tau=124.57 +/- 78.30 sec
LSC_B8_DC_mean r=7.10 +/- 2.42 %
LSC_B4_12MHz_MAG_mean tau=102.97 +/- 192.52 sec
LSC_B4_12MHz_MAG_mean r=33.93 +/- 106.92 %


As you can see, B4_DC, B5_DC, B7_DC and B8_DC have very similar time constants and power drop, which indicates power recycling gain decay, something in CITF. You can also see that B7_DC and B8_DC divided by B5_DC stays roughly constant from the time series plot. This means that finnesse of the arms stay roughly constant.
The time constant in June was ~10%, but it increased to ~30% in July. More surprisingly, time constant in June was ~90 sec, but it changed to ~50 sec in July.
B2_DC has slightly different time constant, and have more power drop.
B4_12MHz fluctuates a lot, and it is hard to tell, but it has similar time constant (~100 sec) with B4_DC, and more drop (~30%) compared with B4_DC.

B4_12MHz decaying faster than B4_112MHz indicate some alignment drift or abbreation drift at O(100) sec time scale, since 6 MHz is more sensitive to these effects.


Next:
 - Try not decreasing 6 MHz as much to see the behaviour of 6 MHz in DF, if possible.
 - Look for the mirror temperature drift (but it might be hard since line tracker (logbook #41883) demodulates B1, not B1p; B1 is not available in LOCKED_PRITF_DF and B1p is noisier).

Images attached to this comment
Optical characterization (Optical characterization)
Allocca, chiummo, Michimura - 12:24 Monday 30 July 2018 (42240) Print this report
Comment to Where is the power lost? (42058)

Trying to dig further into the issue of power drop. One hypothesis was: is it possible that the power drop is fake and what actaully changes is the PDs response due to some heating? Unlikely.

Indeed, attached pictures show a lock acquisition just after the latest power increase

GPS = 1214067761; GPSdur = 7*60; % first lock acquisition after power increase 12W->25W Jun 26 2018

In this case, we plot the power recorded by two different kinds of sensors: photodiodes B7/8/4, and quadrants B4QD. You can see that the behavior is very similar and the ratio between the two kinds of sensors stays basically constant. So it seems we are dealing with something really happening.

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
michimura - 12:11 Thursday 26 July 2018 (42219) Print this report
Comment to DC power and RF sideband power at different MICH offsets (42116)

For a quick check, I made a comparison of lock sequences between June 23 when we achieved 35Mpc at 13W and the current one at 25W.
Although there are big fluctuations and hard to tell, most of the sideband powers at B1p, B2, B4 seem reasonably scaled with power change. B4 8MHz power seems a bit higher (~ x4) than expected from dark fringe, and B4 112MHz power seems a bit lower (~ 1/2) than expected in Low Noise 1. B4 8MHz being higher could be related to PRCL servo (not enough gain? bad demodulation phase tuning?). B4 112MHz being less suggest less 56MHz build up in PRC (thermal lensing? alignment?). Further investigations necessary.


Lock sequence:
DCchannelsTimeseries1213988098.png is the plot showing time series of Metatron states, DC power at B1p/B2/B4 and modulation amplitudes on June 25. If you compare it with the same plot on July 23 (DCchannelsTimeseries1216413100.png in logbook #42201), you can see that power on B1p and B4 is doubled, and power on B2 is now half.

RF PD spectra with RMS:
RFchannelsSpectra1213988098.png is the spectra of RF PDs from June 25. Compared with the spectra from July 23 (RFchannelsSpectra1216413100.png in logbook #42201), you can see that there were many harmonics in B2 and B1p, even we were at 13W.

Demodulated signals of RF PDs:
The time series data of demodulated amplitudes at 6MHz, 8MHz, 56MHz and their 2nd harmonics are generated (see attached figures; links in table below). Since SDB2_B1p_PD2_sample, SIB2_B2_PD2_sample, SPRB_B4_PD2_sample are only saved 32768 samples per second (8.192e-05 seconds per second), I demodulated the data in one chunk of 32768 samples to give the demodulation amplitude for each second. The demodulation was done using the frequency stored at INJ_LNFS_FREQ{1|2|3}.

6MHz, 8MHz and 56MHz are generated by the beat between the carrier and the sideband. Therefore, their power should scale as modulation depth times DC power. 12MHz, 16MHz and 112MHz are generated by the beat between upper and lower sidebands. Therefore, their power should scale as modulation depth squared times DC power.

Below is the summary table of modulation amplitudes in dBm at the starting point of the MICH offset reduction and at Low Noise 1 in June 25 and July 23, and how DC and RF power on B1p, B2, B4 changed.

        June 25       July 23        B1p           B2                         B4
DC power                             ~doubled      ~half                      ~doubled
                                     [as expected]

6MHz    15dBm->-15dBm 15dBm->-15dBm  ~doubled      ~half                      ~doubled
12MHz                                ~doubled      ~half                      ~doubled
        figure        figure         [no anomaly from expectation found]

8MHz    15dBm          5dBm          ~half [0.6]   ~1/10~1/2 [0.2]            ~1/3->~2 [0.6]
16MHz                                ~1/3 [0.2]    ~1/20~1/10 [0.05]          ~1/3 [0.2]
        figure        figure         [expectations in []; no anomaly from expectation, but B4 8MHz seems higher from DF]

56MHz   12dBm          7dBm->1dBm    ~same->half   bit less than [half->1/4]  ~same->half
112MHz                               ~half->1/4    ~1/10 [1/4->1/8]           ~half->1/4 (but ~1/10 LN1)
        figure        figure         [no anomaly from expectation, but B4 112MHz seems lower at LN1]



Note that INJ_LNFS_AMPL{1|2|3} being zero between MICH_OFFSET_0_2 and _0_1 in the plots for June 25 is fake due to some data error. I confirmed that INJ_LNFS_FREQ{1|2|3} are also zero at this moment, which is very unlikely real.

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
michimura - 23:07 Tuesday 24 July 2018 (42201) Print this report
Comment to DC power and RF sideband power at different MICH offsets (42116)

I checked RF PD saturation situation after a lot of sideband power decrease during MICH offset reduction (see logbook #42162 and #42188).
RMS of the photodiode signals seem to be limited by the main sidebands, and most offending sideband is now 6MHz at MICH offset of 0.1 to 0.0.
If we want to have more range in the future with current locking scheme, we might want to notch 6MHz for B1p and B4.

Lock sequence:
  To visualize the lock sequence, I made a time series plot of Metatron states, DC power at B1p/B2/B4 and modulation amplitudes.
  DCchannelsTimeseries1214577932.png is the plot on July 2 (after nominal 56MHz modulation depth reduction from 12dBm to 7dBm).
  6MHz starts with 15dBm, but reduced to 9dBm during MICH offset reduction from 0.3 to 0.2. It is further reduced to -15dBm in DF.
  8MHz and 56MHz are kept at 15dBm and 7dBm respectively during the whole lock acquisition.

  DCchannelsTimeseries1216413100.png is the plot on July 23, when we reached Low Noise 3 (see #42188).
  6MHz is reduced from 15dBm to 5dBm during MICH offset reduction from 0.2 to 0.1. And then it is further reduced to -15dBm in DF.
  8MHz is reduced from 15dBm to 5dBm during transition from LOCKED_SSFS to LOCKED_PRITF.
  56MHz is reduced from 7dBm to 1dBm during MICH offset reduction from 0.2 to 0.1.

RF PD spectra with RMS:
  RFchannelsSpectra1214577932.png is the spectra from July 2 and RFchannelsSpectra1216413100.png is the spectra from July 23.
  Dashed line shows the RMS and dots show the most RMS-contributing frequency.
  You can see the RMS reduction and saturation reduction especially at MICH offset of 0.1.

Demodulated signals of RF PDs:
  I also plotted the time series data of demodulated amplitudes at 6MHz, 8MHz, 56MHz, 12MHz, 16MHz, 112MHz, and 2MHz of B1p/B2/B4 400MHz raw signals.
  DemodulationTimeseries1214579100.png is that for July 2 and DemodulationTimeseries1216413300.png is that for July 23.
  From July 2, you can see that 6MHz and 56MHz were high (and oscillating!) at B1p at MICH offset of 0.1. 16MHz and 2MHz were also killing B2 from MICH offset reduction to DF.
  On July 23, the situation is much better. You can see that modulation depth reduction is effectively reducing amplitudes of one of the highest sidebands (note that INJ_LNFS_AMPL# has some delay and actual sideband power reduction happens O(10) sec before).
  You can also see that the sideband which has largest amplitude during the lock sequence is 6MHz.

Images attached to this comment
AdV-ISC (Subsystem management)
michimura - 22:14 Monday 23 July 2018 (42186) Print this report
Comment to PyQt graphical user interfaces for ISC (42150)

I also made a GUI for ISC photodiodes, which can be used to monitor DC and RF signals, and to tune demodulation phases (screenshot attached).
Latest stable version live in /virgoDev/PyIscGui/.
You can open the GUI by

> python ISCphotodiodes.py


Details:
 - Use _phi0 channels to tune the demodulation phase (_phi0_offset for SSFS_B4)

 - You can also press Enter/Return key to apply values (you don't have to click "Apply" button). This is also true for LSCoverview.py and ASCoverview.py.

 - "datadisplay" buttons show the data display which can be used to tune demodulation phases. The configuraton file for the data display live in /olusers/virgorun/ISC/dataDisplay.

 - It also shows the current values of channels to select PD1 and PD2 so that it is apparent which photodiodes are used and what gain we have between PD1/PD2 and the combined signal sent to LSC. To get these channels with ConnectOnline, I had to connect with something like 'V1:SNEB_B7' (not 'V1:SNEB'). To monitor the weight channels, I added/modified the following lines in Acl configurations files:

SNEB_Photodiodes.cfg line 265
ACL_SMS    "SNEB_"    B7_6MHz_I    B7_6MHz_Q    B7_56MHz_I    B7_56MHz_Q    B7_DC;

SWEB_Photodiodes.cfg line 250
ACL_SMS    "SWEB_"    B8_6MHz_I    B8_6MHz_Q    B8_56MHz_I    B8_56MHz_Q    B8_DC;

SIB2_Photodiodes.cfg line 423
ACL_SMS    "SIB2_"    B2_6MHz_I    B2_6MHz_Q    B2_8MHz_I    B2_8MHz_Q    B2_DC;

SDB2_Photodiodes.cfg line 779-782
ACL_SMS "SDB2_"    B1p_DC_20kHz    B1p_6MHz_I    B1p_6MHz_Q    B1p_8MHz_I    B1p_8MHz_Q    B1p_56MHz_I    B1p_56MHz_Q;
ACL_SMS "SDB2_"    B1s1_DC_20kHz    B1s1_6MHz_I    B1s1_6MHz_Q;
ACL_SMS "SDB2_"    B1s2_DC_20kHz;
ACL_SMS "SDB2_"    B5_DC_20kHz    B5_6MHz_I    B5_6MHz_Q;

SPRB_Photodiodes.cfg line 428
ACL_DAQ            "SPRB_"    ""    B4_PD_select


 - Photodiode channels are not symmetric. Very confusing. Below are the list of exceptions;
  - SNEB_B7_PD#_DC_100Hz and SWEB_B8_PD#_DC_100Hz exists, but not _DC
  - SPRB_B4_PD_select is used for PD selection, not weights
  - PD#_Blended signals, not PD#_DC are used for SNEB_B7, SWEB_B8, SDB2_B5, SDB2_B1s1, SDB2_B1s2
  - SNEB_B7_PD1_56MHz, SWEB_B8_PD2_56MHz, SIB2_B2_PD1_8MHz, SDB2_B5_PD1_6MHz, SDB2_B1s1_PD2, SDB2_B1s2_PD2 channels do not exist
  - SIB2_B2_PD1_6MHz, SIB2_B2_PD1_DC and SDB2_B5_PD1_DC exist, but weights do not exist
  - for SDB2 PDs, weight channels are *_PD#_DC_20kHz_*, not *_PD#_DC_*


IscGui.py for parsing and showing GUI:
 I also made a script IscGui.py which parses the Qt GUI configuration file (*.ui) and show the GUI. For example, you can also open ISC Photodiodes screen with

> python IscGui.py ISCphotodiodes.ui

 This is useful because you only need to make .ui file with Qt Designer to make a new GUI. However, it can only parse limited widgets with certain names, and give fixed functions to them. Below are the widgets IscGui.py can handle.

Widget class   Name                          Function
QLineEdit      {channelname}_value           show the current value (QTextEdit for showing current filter name)
QPushButton    {channelname}_apply           apply the requested value in QLineEdit explained below
QLineEdit      {channelname]_request         enter the requested value
QPushButton    {channelname}_filter_apply    apply the filter requested in QTextEdit explained below
QTextEdit      {channelname}_filter_request  enter the requested filter
QPushButton    {channelname}_weight_apply    apply the weight for the input channel in QComboBox with the requested weight in QLineEdit explained below
QComboBox      {channelname}_channel_request select the requested input channel
QTextEdit      {channelname}_weight_request  enter the requested weight
QLineEdit      {channelname}_channel_1 or _2 show the input channels which has the largest and second largest weight
QLineEdit      {channelname}_weight_1 or _2  show the largest and second largest weight


 I think this is useful to initiate GUIs (but the final versions should be different python codes for different .ui files for maintenance point of view).

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
bersanetti, michimura - 1:19 Friday 20 July 2018 (42162) Print this report
ITF Recovery: back in LOW_NOISE_1, 6 MHz and 8 MHz modulation amplitudes reduced

This afternoon we carried on the recovery of the ITF:

  • the West arm was realigned and relocked;
  • we performed the tuning of FmodErr: since we did not do that for a very long time, the misplacement of MC_Z was quite big; this led to the first occurrence of the problem described in #42159 and to the re-discussion about how to deal with the master laser's thermal correction when FmodErr is engaged; probably the best thing will be to hasten the re-deployment of the old calibrated FmodErr, hopefully next week;
  • after that we began to recover the ITF and to study the saturation issues arised in the lock acquisition since the increase of the input power:
    • we reverted all the changes done for the SDB1 intervention without stumbling into any issue;
    • we did a standard lock acquisition and we noticed that, near and at dark fringe, the B2 photodiode is the one saturating the most, mostly due to the 16 MHz, coherently with what Julia and Yuta recently reported and the thresholds reported by DET people (B2_PD2_sample above 0.4 mW, see Figure 1);
    • we investigated by hand reducing the modulation amplitude for the 8 MHz sideband during the MICH offset reduction, and at MICH_SET = 0.3 we are above the threshold, and at 0.5 we are already close enough; we reduced the modulation amplitude from 15 dBm to 9 dBm for the whole lock acquisition (but resetting it in DOWN, since it is also used for FmodErr) and things got better, however in dark fringe there was still saturation of such sidebands, so we reduced it further down to 6 dBm; both PRCL and the PR alignment loops were adjusted in gain but they did not seem to suffer from the reduced signal;
    • at this point it was noticeable that the 6 MHz sideband was still causing trouble on B2, so we tried to reduce it even more at MICH_SET = 0.2, from 9 dBm to 6 dBm; despite the very bad SNR, B7 and B8 were still usable, so we left it as default since it was definitely improving things;
    • in Figure 2 there is the comparison at MICH_SET = 0.1 between July 2nd and tonight, where the [6, 8, 56] MHz modulation amplitudes were respectively [9, 15, 7] and [5, 5, 7];
    • at this point we managed a few times to reach dark fringe and, eventually, LOW_NOISE_1; statistics is not high, but the locks seem quite promising;
    • at a first glance, the alignment loops seem to work fine, maybe some fine tuning of their working point for 25 W is needed, since we didn't do that before the Commissioning Break;
    • we tried once to lock OMC1: as expected the temperature scan took a long time, given the several interventions and the long shutdown; starting from the usual temperature of 22.69 °C, we could find a good amount of power on B1s2 at 22.745 °C but the scan went on, then at 22.86 °C another was found, but the temperature reset happened just after; at the second attempt I manually ramped up to 22.745 °C but then the OMC locked on a 1st order mode and the DARM hand-off failed (see Figure 3); in the end I reverted manually the temperature to 22.69 °C and we gave up for the night;
    • Figure 4 is Yuta's GUI showing the overview of the ITF when we're locked in LOW_NOISE_1, with all the powers nicely scaled also visually.

We left the ITF in LOCKED_RECOMBINED with the FmodErr tuning disabled.


Side notes:

  • the West arm is usually quite shaky after an unlock, and sometimes the 7 Hz shows up a bit in DARM, but it does not build up as before;
  • looking at the PD signals, we could correlate the flashes we see on the B7/B8 powers when near dark fringe with similar flashes on SIB2_B2_PD2_RF_{min,max};
  • the LNFS bug reported in #42015 is still there: for "low" modulation amplitudes, the LNFS somewhat misses the correct integer, and selects the closest one: for this reason, the 6 MHz sideband is reduced to nominally 6 dBm, which become 5 dBm, so the (hardcoded) sanity check is done against 5 dBm; the same happens to the 8 MHz sideband, but there is no check (yet);
  • the change of the 8 MHz amplitude is done in the old way with the external script, as the current PyLNFS100 package doesn't have the appropriate cm handler; however, this is trivial to implement and it will be done tomorrow; looking at a few sequences, I did not find any issue with the commands already present in the DOWN state, while the other ones happen in different places altogether;
  • all the "8 MHz" gains were rescaled by hand, but in the ITF_LOCK.ini file there are the old values, the values for 9 dBm and the current ones for 5 dBm; if we think to stick to this, I will setup something similar to what we already have for the 56 MHz gains;
  • since the further reduction of the 6 MHz amplitude requires a bigger increment of the DARM gain, and given the different places they must be done into, such increment at MICH_SET = 0.2 uses twice the ramp w.r.t. the other gains/setpoints, so the asynchronicity between ramps is done on purpose;
  • the 100 Hz line and its harmonics are HUGE, always polluting PRCL (see Figure 5) and sometimes DARM, but they're not particularly impacting on the corrections (see Figure 6); however, a number of unlocks are due to this PRCL weakness;
  • most of the unlocks when trying to go to dark fringe after the reduction of the modulation amplitudes (after 18:50 UTC onwards) are due to the fact that the transfer function between MICH before and at dark fringe (B1p_SUM_NORM and SSFS_B4_56MHz_Q respectively) changed sign for unknown reasons.
Images attached to this report
Comments to this report:
mwas - 8:14 Friday 20 July 2018 (42164) Print this report
OMC1 didn't lock because it is strongly misaligned, the TEM00 and TEM10 mode have about the same height (see figure). Most likely because of the large change in PR vertical position needed yesterday to recover the ITF. SDB1 changed in LC_TX from -210urad to -130urad to follow, but the SDB1 drift control is only in the 2 dominant degrees of freedom not 4. Some more alignment of OMC1 on the single bounce from NI beam will be needed.
Images attached to this comment
AdV-ISC (Subsystem management)
michimura - 20:37 Wednesday 18 July 2018 (42150) Print this report
PyQt graphical user interfaces for ISC

I made GUIs for ISC using PyQt with a lot of help from Bas, Julia, Diego and Franco.
So far, we have

LSCoverview.py for overviewing length sensing and control (see below).
ITFmonitor.py for monitoring the interferometer locking status (see attached; there's too much light on B1 since work on detection bench is currently underway).
ASCoverview.py for overviewing alignment sensing and control (see attached).

42150_20180718202750_lscoverview.png

Latest stable versions of all of them live in /virgoDev/PyIscGui/.
They can be run by

> python LSCoverview.py

They need relevant .ui files for generating the screen, and .ui files can be edited using Qt Designer.

> designer LSCoverview.ui

I hope this will be the first step to making GUIs for ISC and helping people understand what's happening in ISC.

Next:
 - find a better solution for drawing the interferometer for ITFmonitor.py
 - incorporate driving matrices in DSP
 - make a GUI for tuning demodulation phases
 - make a GUI for SSFS and OMC
 - re-make violin GUI in PyQt (it was made with Tkinter)

Details:
 All of these are based on Python PyQt4. To get all the current values, ConnectOnline function in virgotools is used. To push the requested values, cm_send commands are used. SMS channels are found to be very useful. SMS channels can be acquired only with prefixes:

self.connection=ConnectOnline('FbmPyAccess', 'V1:LSC')
frame = self.connection.get_next_frame()


 Widgets are named consistently so that

- QLineEdit for showing current value has the name {channelname]_value (they are dark grey when signal not acquired, grey when zero, green when not zero)
- QLineEdit for inputting requested value has the name {channelname}_request (they are white)
- QPushButton for applying the value has the name {channelname}_apply

 Right now, codes only talk to Acl.

Below are some notes on each code.

LSCoverview.py
 - As for the input channels (error signals), channels which has largest and second largest weights are shown. Input channels are sum channels and their weights are saved as SMS channels with the name something like "V1:LSC_MICH_INPUT_B4_DC."
 - You can change the weights by selecting the channels in combobox. This will zero all the other weights.
 - Control filters for {DOF}_OUT are also shown. I found that it is saved as SMS channels with the name something like "V1:LSC_MICH_OUT_MICH_control_MICH_mains."
 - Driving matrix is saved as SMS channels with the names something like "V1:LSC_BS_CORR_MICH_CORR."
 - You have to be careful about the driving matrix because you have another matrix in DSP.
 - You can set the ramp time at top-right.

ITFmonitor.py
 - Interferometer is drawn by PyQt4.QtGui.QPainter and the rest is designed by Qt Designer.
 - To change the interferometer drawing, you have to look into the code (which is not very nice and we are seeking for another solution).
 - The thickness of the beams are changed depending on the powers on photodiodes, and you can monitor which parts are locked.
 - Normalization factor for beam thickness have to be re-tuned later once we have a full lock.

ASCoverview.py
 - To save sensing and driving matrices, I added the following lines to the ASC_Acl.cfg file.
ACL_SMS        "ASC_"        BS_TX_INPUT    PR_TX_INPUT    DIFFp_TX_INPUT    DIFFm_TX_INPUT    COMMp_TX_INPUT    COMMm_TX_INPUT
ACL_SMS        "ASC_"        BS_TY_INPUT    PR_TY_INPUT    DIFFp_TY_INPUT    DIFFm_TY_INPUT    COMMp_TY_INPUT    COMMm_TY_INPUT
ACL_SMS        "ASC_"        NE_TX_CORR    NI_TX_CORR    WE_TX_CORR    WI_TX_CORR
ACL_SMS        "ASC_"        NE_TY_CORR    NI_TY_CORR    WE_TY_CORR    WI_TY_CORR

 - The matrix part of the GUI can be auto generated using generateMatrixUI.py.
 - Somehow, COMM{p|m}_{TX|TY}_CORR are not saved as ADC channels (so they are dark grey in the ASCoverview screen). We have to fix this.

Images attached to this report
Comments to this report:
bersanetti - 1:47 Thursday 19 July 2018 (42152) Print this report

First of all, great work for the GUIs! yes

 

About the COMM{p|m}_{TX|TY}_CORR channels, this most probably happens because they were not exported yet as ACL_DAQ objects (on Acl there is still only the sensing, so they are carrying the same information as the COMM{p|m}_{TX|TY} channels, which were already exported); I replicated for them the same exports we have for DIFF{p|m} (lines 489-490 of ASC_Acl), so everything will hopefully be working after the ASC_Acl process is restarted.

michimura - 22:14 Monday 23 July 2018 (42186) Print this report

I also made a GUI for ISC photodiodes, which can be used to monitor DC and RF signals, and to tune demodulation phases (screenshot attached).
Latest stable version live in /virgoDev/PyIscGui/.
You can open the GUI by

> python ISCphotodiodes.py


Details:
 - Use _phi0 channels to tune the demodulation phase (_phi0_offset for SSFS_B4)

 - You can also press Enter/Return key to apply values (you don't have to click "Apply" button). This is also true for LSCoverview.py and ASCoverview.py.

 - "datadisplay" buttons show the data display which can be used to tune demodulation phases. The configuraton file for the data display live in /olusers/virgorun/ISC/dataDisplay.

 - It also shows the current values of channels to select PD1 and PD2 so that it is apparent which photodiodes are used and what gain we have between PD1/PD2 and the combined signal sent to LSC. To get these channels with ConnectOnline, I had to connect with something like 'V1:SNEB_B7' (not 'V1:SNEB'). To monitor the weight channels, I added/modified the following lines in Acl configurations files:

SNEB_Photodiodes.cfg line 265
ACL_SMS    "SNEB_"    B7_6MHz_I    B7_6MHz_Q    B7_56MHz_I    B7_56MHz_Q    B7_DC;

SWEB_Photodiodes.cfg line 250
ACL_SMS    "SWEB_"    B8_6MHz_I    B8_6MHz_Q    B8_56MHz_I    B8_56MHz_Q    B8_DC;

SIB2_Photodiodes.cfg line 423
ACL_SMS    "SIB2_"    B2_6MHz_I    B2_6MHz_Q    B2_8MHz_I    B2_8MHz_Q    B2_DC;

SDB2_Photodiodes.cfg line 779-782
ACL_SMS "SDB2_"    B1p_DC_20kHz    B1p_6MHz_I    B1p_6MHz_Q    B1p_8MHz_I    B1p_8MHz_Q    B1p_56MHz_I    B1p_56MHz_Q;
ACL_SMS "SDB2_"    B1s1_DC_20kHz    B1s1_6MHz_I    B1s1_6MHz_Q;
ACL_SMS "SDB2_"    B1s2_DC_20kHz;
ACL_SMS "SDB2_"    B5_DC_20kHz    B5_6MHz_I    B5_6MHz_Q;

SPRB_Photodiodes.cfg line 428
ACL_DAQ            "SPRB_"    ""    B4_PD_select


 - Photodiode channels are not symmetric. Very confusing. Below are the list of exceptions;
  - SNEB_B7_PD#_DC_100Hz and SWEB_B8_PD#_DC_100Hz exists, but not _DC
  - SPRB_B4_PD_select is used for PD selection, not weights
  - PD#_Blended signals, not PD#_DC are used for SNEB_B7, SWEB_B8, SDB2_B5, SDB2_B1s1, SDB2_B1s2
  - SNEB_B7_PD1_56MHz, SWEB_B8_PD2_56MHz, SIB2_B2_PD1_8MHz, SDB2_B5_PD1_6MHz, SDB2_B1s1_PD2, SDB2_B1s2_PD2 channels do not exist
  - SIB2_B2_PD1_6MHz, SIB2_B2_PD1_DC and SDB2_B5_PD1_DC exist, but weights do not exist
  - for SDB2 PDs, weight channels are *_PD#_DC_20kHz_*, not *_PD#_DC_*


IscGui.py for parsing and showing GUI:
 I also made a script IscGui.py which parses the Qt GUI configuration file (*.ui) and show the GUI. For example, you can also open ISC Photodiodes screen with

> python IscGui.py ISCphotodiodes.ui

 This is useful because you only need to make .ui file with Qt Designer to make a new GUI. However, it can only parse limited widgets with certain names, and give fixed functions to them. Below are the widgets IscGui.py can handle.

Widget class   Name                          Function
QLineEdit      {channelname}_value           show the current value (QTextEdit for showing current filter name)
QPushButton    {channelname}_apply           apply the requested value in QLineEdit explained below
QLineEdit      {channelname]_request         enter the requested value
QPushButton    {channelname}_filter_apply    apply the filter requested in QTextEdit explained below
QTextEdit      {channelname}_filter_request  enter the requested filter
QPushButton    {channelname}_weight_apply    apply the weight for the input channel in QComboBox with the requested weight in QLineEdit explained below
QComboBox      {channelname}_channel_request select the requested input channel
QTextEdit      {channelname}_weight_request  enter the requested weight
QLineEdit      {channelname}_channel_1 or _2 show the input channels which has the largest and second largest weight
QLineEdit      {channelname}_weight_1 or _2  show the largest and second largest weight


 I think this is useful to initiate GUIs (but the final versions should be different python codes for different .ui files for maintenance point of view).

Images attached to this comment
michimura - 17:12 Wednesday 01 August 2018 (42280) Print this report

I made a GUI for ISC quadrants, which can be used to monitor DC and RF signals, and to tune demodulation phases (see ISCquadrants.png).
The latest stable version live in /virgoDev/PyIscGui/.
You can open the GUI by

> python ISCquadrants.py


Details:
 - For quadrants, there are _phi0 channels to rotate I and Q both in the suspended bench and ASC.

 - "datadisplay" buttons show the data display which can be used to tune demodulation phases. The configuraton file for the data display live in /olusers/virgorun/ISC/dataDisplay. "datadisplay 1" for QD1 and "datadisplay 2" for QD2.

 - Some of _phi0 channels in ASC were not stored, so I added the following channels in the last line ACL_DAQ_FILTER (line 511) in ASC_Acl.cfg.

B1p_QD1_H_56MHz_phi0    B1p_QD1_V_56MHz_phi0    B1p_QD2_H_56MHz_phi0    B1p_QD2_V_56MHz_phi0
B4_QD1_H_56MHz_phi0    B4_QD1_V_56MHz_phi0    B4_QD2_H_56MHz_phi0    B4_QD2_V_56MHz_phi0
B2_QD1_H_8MHz_phi0    B2_QD1_V_8MHz_phi0


 - Channels for quadrants are made symmetric and it was very easy to make a GUI yes.

 - Currently, B1p QD2 56MHz, B2 QD2 8MHz, B5 QD2 56MHz, B5 QD2 norm, B5 QD2 56MHz are used (see ASC sensing matrix). There are no ASC channels for B2 6MHz and B5 6MHz.


Some updates:
 - Now the launcher screen for ISC is available (Launcher.py; see Launcher.png).
 - Now you can shrink the screens and they will be scrollable (something like this).

Images attached to this comment
michimura, carbognani - 14:36 Monday 06 August 2018 (42345) Print this report

Series of PyQt ISC GUIs have been packaged as PyIscGui and the first version has been uploaded in /virgoApp/PyIscGui/v1r0/

This version has also been added under the IceWM menu ISC section and ISC Lancher GUI can be started from there (see attached). ISC Launcher now can launch the following GUIs

- ITF Monitor (logbook #42150)
- LSC Overview (logbook #42150)
- ASC Overview (logbook #42150)
- ISC Photodiodes (logbook #42186)
- ISC Quadrants (logbook #42280)
- Violing Damping (logbook #42344)

Previous Tkinter version of violinUI in SUS section has been removed from IceWM (see, also, logbook #41997).

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
michimura - 13:26 Friday 13 July 2018 (42116) Print this report
DC power and RF sideband power at different MICH offsets

After input power increase to 25W, PDs seems to be saturated.
I checked what sideband powers are high at B1p, B2, and B4 photodiodes at different MICH offsets.

Summary:
 - Sideband behaviour at B2 looks reproducable.
 - Sideband power at B1p and B4 fluctuates between locks, especially when MICH offset is 0.2 to 0.0. Maybe this is from different alignment conditions, which result in the different sideband power build-up for different modulation frequencies (see, also lobgook #42011 (6MHz decay) and #41817 (56MHz decay)).
 - B4_DC decays at dark fringe quite rapidly (see also logbook #42058).


Possible solution:
 If my understanding of the lock sequence is correct......
 - For B1p, we can notch 12MHz and 2MHz since we are not using these at B1p.
 - For B4, it's hard to notch because we are using 12MHz (for sideband power monitor), 56MHz (for SSFS). We can notch 2MHz. We can also try reducing modulation depth of 6MHz and 56MHz.
 - For B2, we can notch 16MHz. We can also try reducing modulation depth of 8MHz and 56MHz.


Detailed results:
DC power and RF power at different MICH offsets for 3 lock sequences with different conditions are listed below.
For each lock sequence, DC power evolution and modulation depth change with MICH offset change, and spectra of RF PD signals are attached.
In the spectra, color corresponds MICH offsets as;
 - 0.7: red
 - 0.5: yellow
 - 0.3: green
 - 0.2: cyan
 - 0.1: blue
 - 0.0: magenta
 - no light: black (taken this morning)


From gps = 1214554740 (2018-07-02 08:18:42 UTC) Figure of DC signals, Figure of RF PD spectra
(original 25 W, did not reached DF)
DQ_META_ITF_State       103.    105.    107.    110.    112.    
LSC_MICH_SET              0.70    0.50    0.30    0.20    0.10  
LSC_B1p_DC_mean           1.85    2.93    4.80    6.46    8.78  
LSC_B2_DC_mean           17.36   15.55   12.70   10.14    5.64  
LSC_B4_DC_mean            0.08    0.28    1.07    2.46    7.53  
DAQ_LNFS_6MHz_mag_mean    0.57    0.57    0.57    0.28    0.28 (reduced towards dark fringe)
DAQ_LNFS_8MHz_mag_mean    1.10    1.10    1.10    1.10    1.10  
DAQ_LNFS_56MHz_mag_mean   0.31    0.31    0.31    0.31    0.31


B1p_PD2 highest freq      2MHz   12MHz   12MHz    6MHz    6MHz
B1p_PD2 highest mag       3e-4    9e-4    1e-3    1e-3    2e-3 [mW/rtHz]
B1p_PD2 2nd high freq    12MHz    6MHz    6MHz   12MHz   56MHz
B1p_PD2 2nd high mag      2e-4    6e-4    9e-4    4e-4    1e-3 [mW/rtHz]
B1p_PD2 3rd high freq    14MHz    2MHz    2MHz    2MHz   12MHz
B1p_PD2 3rd high mag      2e-4    5e-4    5e-4    2e-4    4e-4 [mW/rtHz]

(mostly same as MICH offset reduction starting from gps = 1214556256 below, but different at 0.2-0.1 offset)

B4_PD2 highest freq       2MHz   12MHz   12MHz   56MHz   56MHz
B4_PD2 highest mag        1e-5    9e-5    2e-4    4e-4    5e-4 [mW/rtHz]
B4_PD2 2nd high freq     14MHz   56MHz   56MHz   12MHz   12MHz
B4_PD2 2nd high mag       1e-5    7e-5    2e-4    1e-4    4e-4 [mW/rtHz]
B4_PD2 3rd high freq     12MHz    2MHz    2MHz    2MHz   50MHz
B4_PD2 3rd high mag       1e-5    5e-5    9e-5    7e-5    1e-4 [mW/rtHz]

(mostly same as MICH offset reduction starting from gps = 1214556256 below)

B2_PD2 highest freq       6MHz    6MHz    6MHz   56MHz   16MHz
B2_PD2 highest mag        2e-5    1e-3    1e-3    1e-3    1e-3 [mW/rtHz]
B2_PD2 2nd high freq      2MHz   56MHz   56MHz   12MHz    2MHz
B2_PD2 2nd high mag       1e-5    9e-4    1e-3    1e-3    6e-4 [mW/rtHz]
B2_PD2 3rd high freq     14MHz   12MHz   12MHz   16MHz   14MHz
B2_PD2 3rd high mag       1e-5    7e-4    7e-4    7e-4    5e-4 [mW/rtHz]

(mostly same as the MICH offset reduction starting from gps = 1214556256 below)


From gps = 1214556256 (2018-07-02 08:43:58 UTC) Figure of DC signals, Figure of RF PD spectra
(after B1p saturation fixed)
DQ_META_ITF_State       103.    105.    107.    110.    112.    120.    
LSC_MICH_SET              0.70    0.50    0.30    0.20    0.10    0.00   
LSC_B1p_DC_mean           1.85    2.93    4.80    6.51    8.86    0.25  
LSC_B2_DC_mean           17.44   15.81   12.85   10.10    5.64    2.88  
LSC_B4_DC_mean            0.08    0.28    1.07    2.48    7.60   44.37
DAQ_LNFS_6MHz_mag_mean    0.57    0.57    0.57    0.28    0.28    0.03 (reduced towards dark fringe)
DAQ_LNFS_8MHz_mag_mean    1.10    1.10    1.10    1.10    1.10    1.10  
DAQ_LNFS_56MHz_mag_mean   0.31    0.31    0.31    0.31    0.31    0.31


B1p_PD2 highest freq     12MHz   12MHz   12MHz   56MHz   56MHz    8MHz
B1p_PD2 highest mag       7e-4    9e-4    1e-3    4e-4    5e-4    5e-5 [mW/rtHz]
B1p_PD2 2nd high freq     6MHz    2MHz    6MHz   12MHz   12MHz  112MHz
B1p_PD2 2nd high mag      6e-4    5e-4    5e-4    4e-4    5e-4    9e-6 [mW/rtHz]
B1p_PD2 3rd high freq     2MHz    6MHz    2MHz    6MHz    8MHz   56MHz
B1p_PD2 3rd high mag      5e-4    4e-4    5e-4    3e-4    3e-4    4e-6 [mW/rtHz]

(12MHz at 0.3 offset is highest, 2MHz is also high)

B4_PD2 highest freq      12MHz   12MHz   12MHz   56MHz   56MHz    8MHz
B4_PD2 highest mag        3e-5    9e-5    2e-4    2e-4    7e-4    1e-4 [mW/rtHz]
B4_PD2 2nd high freq      2MHz   56MHz   56MHz   12MHz   12MHz   16MHz
B4_PD2 2nd high mag       3e-5    6e-5    2e-4    1e-4    2e-4    1e-4 [mW/rtHz]
B4_PD2 3rd high freq     14MHz    2MHz    2MHz    2MHz    2MHz   48MHz
B4_PD2 3rd high mag       2e-5    5e-5    9e-5    7e-5    1e-4    2e-5 [mW/rtHz]

(56MHz at 0.1 offset is highest, 12MHz is also high)

B2_PD2 highest freq       6MHz    6MHz    6MHz   56MHz   16MHz   16MHz
B2_PD2 highest mag        7e-4    1e-3    2e-3    9e-4    1e-3    2e-3 [mW/rtHz]
B2_PD2 2nd high freq     12MHz   56MHz   56MHz   12MHz   56MHz   48MHz
B2_PD2 2nd high mag       5e-4    8e-4    1e-3    7e-4    9e-4    1e-3 [mW/rtHz]
B2_PD2 3rd high freq      2MHz   12MHz   12MHz    6MHz    2MHz   64MHz
B2_PD2 3rd high mag       4e-4    6e-4    7e-4    6e-4    7e-4    8e-4 [mW/rtHz]

(16MHz at dark fringe is highest, 56MHz and 56+/-8MHz are also high)


gps = 1214578932 (2018-07-02 15:01:54 UTC) Figure of DC signals, Figure of RF PD spectra
(after decreasing the power on B2)
DQ_META_ITF_State       103.    105.    107.    110.    112.    120.    
LSC_MICH_SET              0.70    0.50    0.30    0.20    0.10    0.00  
LSC_B1p_DC_mean           1.87    2.97    4.87    6.50    8.78    0.49  
LSC_B2_DC_mean            8.17    7.35    6.03    4.79    2.65    1.24 (~half the DC power)
LSC_B4_DC_mean            0.08    0.28    1.08    2.47    7.52   44.11
DAQ_LNFS_6MHz_mag_mean    0.57    0.57    0.57    0.28    0.28    0.02 (reduced towards dark fringe)
DAQ_LNFS_8MHz_mag_mean    1.10    1.10    1.10    1.10    1.10    1.10  
DAQ_LNFS_56MHz_mag_mean   0.31    0.31    0.31    0.31    0.31    0.31


B1p_PD2 highest freq     12MHz   12MHz   12MHz   12MHz   56MHz  112MHz
B1p_PD2 highest mag       7e-4    9e-4    1e-3    4e-4    2e-3    2e-5 [mW/rtHz]
B1p_PD2 2nd high freq     6MHz    2MHz    6MHz    6MHz    6MHz    8MHz
B1p_PD2 2nd high mag      7e-4    5e-4    6e-4    4e-4    1e-3    1e-5 [mW/rtHz]
B1p_PD2 3rd high freq     2MHz    6MHz    2MHz   56MHz    8MHz    6MHz
B1p_PD2 3rd high mag      5e-4    4e-4    4e-4    2e-4    3e-4    9e-6 [mW/rtHz]

(mostly same as MICH offset reduction starting from gps = 1214556256 above, but different at 0.2-0.0 offset)

B4_PD2 highest freq      12MHz   12MHz   12MHz   56MHz   12MHz   16MHz
B4_PD2 highest mag        3e-5    8e-5    2e-4    3e-4    5e-4    1e-4 [mW/rtHz]
B4_PD2 2nd high freq      2MHz   56MHz   56MHz   12MHz   48MHz    8MHz
B4_PD2 2nd high mag       3e-5    6e-5    2e-4    1e-4    1e-4    4e-5 [mW/rtHz]
B4_PD2 3rd high freq     14MHz    2MHz    2MHz    2MHz   56MHz   48MHz
B4_PD2 3rd high mag       2e-5    5e-5    9e-5    7e-5    1e-4    3e-5 [mW/rtHz]

(mostly same as MICH offset reduction starting from gps = 1214556256 above, but different at 0.2-0.0 offset)

B2_PD2 highest freq       6MHz    6MHz    6MHz   56MHz   16MHz   16MHz
B2_PD2 highest mag        3e-4    6e-4    6e-4    4e-4    5e-4    1e-3 [mW/rtHz]
B2_PD2 2nd high freq     12MHz   56MHz   56MHz   12MHz    2MHz   48MHz
B2_PD2 2nd high mag       3e-4    4e-4    5e-4    3e-4    3e-4    3e-4 [mW/rtHz]
B2_PD2 3rd high freq     56MHz   12MHz   12MHz    6MHz   14MHz   64MHz
B2_PD2 3rd high mag       3e-4    3e-4    4e-4    3e-4    3e-4    2e-4 [mW/rtHz]

(mostly half the MICH offset reduction starting from gps = 1214556256 above, as expected)

Images attached to this report
Comments to this report:
michimura - 23:07 Tuesday 24 July 2018 (42201) Print this report

I checked RF PD saturation situation after a lot of sideband power decrease during MICH offset reduction (see logbook #42162 and #42188).
RMS of the photodiode signals seem to be limited by the main sidebands, and most offending sideband is now 6MHz at MICH offset of 0.1 to 0.0.
If we want to have more range in the future with current locking scheme, we might want to notch 6MHz for B1p and B4.

Lock sequence:
  To visualize the lock sequence, I made a time series plot of Metatron states, DC power at B1p/B2/B4 and modulation amplitudes.
  DCchannelsTimeseries1214577932.png is the plot on July 2 (after nominal 56MHz modulation depth reduction from 12dBm to 7dBm).
  6MHz starts with 15dBm, but reduced to 9dBm during MICH offset reduction from 0.3 to 0.2. It is further reduced to -15dBm in DF.
  8MHz and 56MHz are kept at 15dBm and 7dBm respectively during the whole lock acquisition.

  DCchannelsTimeseries1216413100.png is the plot on July 23, when we reached Low Noise 3 (see #42188).
  6MHz is reduced from 15dBm to 5dBm during MICH offset reduction from 0.2 to 0.1. And then it is further reduced to -15dBm in DF.
  8MHz is reduced from 15dBm to 5dBm during transition from LOCKED_SSFS to LOCKED_PRITF.
  56MHz is reduced from 7dBm to 1dBm during MICH offset reduction from 0.2 to 0.1.

RF PD spectra with RMS:
  RFchannelsSpectra1214577932.png is the spectra from July 2 and RFchannelsSpectra1216413100.png is the spectra from July 23.
  Dashed line shows the RMS and dots show the most RMS-contributing frequency.
  You can see the RMS reduction and saturation reduction especially at MICH offset of 0.1.

Demodulated signals of RF PDs:
  I also plotted the time series data of demodulated amplitudes at 6MHz, 8MHz, 56MHz, 12MHz, 16MHz, 112MHz, and 2MHz of B1p/B2/B4 400MHz raw signals.
  DemodulationTimeseries1214579100.png is that for July 2 and DemodulationTimeseries1216413300.png is that for July 23.
  From July 2, you can see that 6MHz and 56MHz were high (and oscillating!) at B1p at MICH offset of 0.1. 16MHz and 2MHz were also killing B2 from MICH offset reduction to DF.
  On July 23, the situation is much better. You can see that modulation depth reduction is effectively reducing amplitudes of one of the highest sidebands (note that INJ_LNFS_AMPL# has some delay and actual sideband power reduction happens O(10) sec before).
  You can also see that the sideband which has largest amplitude during the lock sequence is 6MHz.

Images attached to this comment
michimura - 12:11 Thursday 26 July 2018 (42219) Print this report

For a quick check, I made a comparison of lock sequences between June 23 when we achieved 35Mpc at 13W and the current one at 25W.
Although there are big fluctuations and hard to tell, most of the sideband powers at B1p, B2, B4 seem reasonably scaled with power change. B4 8MHz power seems a bit higher (~ x4) than expected from dark fringe, and B4 112MHz power seems a bit lower (~ 1/2) than expected in Low Noise 1. B4 8MHz being higher could be related to PRCL servo (not enough gain? bad demodulation phase tuning?). B4 112MHz being less suggest less 56MHz build up in PRC (thermal lensing? alignment?). Further investigations necessary.


Lock sequence:
DCchannelsTimeseries1213988098.png is the plot showing time series of Metatron states, DC power at B1p/B2/B4 and modulation amplitudes on June 25. If you compare it with the same plot on July 23 (DCchannelsTimeseries1216413100.png in logbook #42201), you can see that power on B1p and B4 is doubled, and power on B2 is now half.

RF PD spectra with RMS:
RFchannelsSpectra1213988098.png is the spectra of RF PDs from June 25. Compared with the spectra from July 23 (RFchannelsSpectra1216413100.png in logbook #42201), you can see that there were many harmonics in B2 and B1p, even we were at 13W.

Demodulated signals of RF PDs:
The time series data of demodulated amplitudes at 6MHz, 8MHz, 56MHz and their 2nd harmonics are generated (see attached figures; links in table below). Since SDB2_B1p_PD2_sample, SIB2_B2_PD2_sample, SPRB_B4_PD2_sample are only saved 32768 samples per second (8.192e-05 seconds per second), I demodulated the data in one chunk of 32768 samples to give the demodulation amplitude for each second. The demodulation was done using the frequency stored at INJ_LNFS_FREQ{1|2|3}.

6MHz, 8MHz and 56MHz are generated by the beat between the carrier and the sideband. Therefore, their power should scale as modulation depth times DC power. 12MHz, 16MHz and 112MHz are generated by the beat between upper and lower sidebands. Therefore, their power should scale as modulation depth squared times DC power.

Below is the summary table of modulation amplitudes in dBm at the starting point of the MICH offset reduction and at Low Noise 1 in June 25 and July 23, and how DC and RF power on B1p, B2, B4 changed.

        June 25       July 23        B1p           B2                         B4
DC power                             ~doubled      ~half                      ~doubled
                                     [as expected]

6MHz    15dBm->-15dBm 15dBm->-15dBm  ~doubled      ~half                      ~doubled
12MHz                                ~doubled      ~half                      ~doubled
        figure        figure         [no anomaly from expectation found]

8MHz    15dBm          5dBm          ~half [0.6]   ~1/10~1/2 [0.2]            ~1/3->~2 [0.6]
16MHz                                ~1/3 [0.2]    ~1/20~1/10 [0.05]          ~1/3 [0.2]
        figure        figure         [expectations in []; no anomaly from expectation, but B4 8MHz seems higher from DF]

56MHz   12dBm          7dBm->1dBm    ~same->half   bit less than [half->1/4]  ~same->half
112MHz                               ~half->1/4    ~1/10 [1/4->1/8]           ~half->1/4 (but ~1/10 LN1)
        figure        figure         [no anomaly from expectation, but B4 112MHz seems lower at LN1]



Note that INJ_LNFS_AMPL{1|2|3} being zero between MICH_OFFSET_0_2 and _0_1 in the plots for June 25 is fake due to some data error. I confirmed that INJ_LNFS_FREQ{1|2|3} are also zero at this moment, which is very unlikely real.

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
casanueva, michimura, hardwick - 23:38 Tuesday 26 June 2018 (42004) Print this report
Recovery at 25W

After the increase of the input power we have tried to recover the lock of the ITF. We managed to reach LOW_NOISE1 succesfully with 25 W cool, but we got stucked while locking the OMC1. A few comments:

  • There was a huge oscillation around 10Hz growing caused by the vertical dampers of the cavity mirrors. Paolo told me to de-activate them during the lock acquisition and turn them on in DF. Unfortunately, in DF they were producing the same effect. To be checked tomorrow.
  • When unlocking, the IMC would oscillate more than usual (10urad amplitude oscillations), taking long time to calm down.
  • I anticipated the hand-off to B7/B8 PDs at 0.5 offset, since it would saturate at 0.3.
  • We had an unlock due to shutter closing of the B1p at 0.1 of MICH offset. Romain B. updated the threshold level to mitigate the problem, but it happened few times more. To be monitored.
  • The 6MHz is turned off as it was done in the past.

Tomorrow morning we should start by the lock of the OMC1. We leave the ITF in recombined for the night.

PS. We tested the GUI of the longitudinal loops, changing succesfully some gains and filters! yes

AdV-COM (AdV commissioning (1st part) )
carbognani, michimura - 16:59 Tuesday 26 June 2018 (41997) Print this report
Comment to Violin mode damping (41922)
The violin mode damping GUI has been packaged as violinUI separate package and a production version (v1r1) has been uploaded in /virgoApp:
/virgoApp/violinUI/v1r1

This version has also been added under the IceWM menu SUS section and all declinations of the GUI can be started from there (Fig. 1)
Images attached to this comment
Environmental Monitoring (Environmental Monitoring)
hardwick, michimura - 15:18 Monday 25 June 2018 (41967) Print this report
Comment to Shaking of IB tower (41948)

We've looked at the times during shaker injections. We suspect that 101 Hz is not caused by the RFC minilink or by some structure on the suspended bench, but perhaps by some structure attached to the chamber wall inside (is there some lip where the minilink meets the wall that could have its own resonance?).

  • 101 Hz is not a resonance of the RFC minilink. We see no resonant peak in the minilink accelerometer. While there is coherence around 101 Hz between RFC Err and accelerometer, there is less coherence right at the 101 Hz peak seen in RFC Err. 
  • 101 Hz is not a resonance of some structure on the bench. Noise in Sc_MC_RFC_Err_Post scales as 1/2 the RFC minilink motion (IB_BD_ACC) and the same as chamber wall motion (IB_ACC_X).  Unless there is a mechanical short between the chamber wall and the suspended bench, motion of some bench structure (optics mount, etc.) should be attentuated relative to chamber wall motion.
  • Additionally, this doesn't look like two structures moving/modulating scattered light; the motion of the chamber wall/minilink is large (10-4 m/s2) compared to wavelength, so we would expect broad noise peak, not the narrow line we see in RFC Err/DARM.

I attach spectrum during no injections and two different shaker injections, showing the accelerometers and error signals mentioned in original post. In the plots: purple is no injection, green is 75-125 Hz shaker injection, and blue is 95-105 Hz shaker injection.

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
hardwick, michimura - 19:11 Friday 22 June 2018 (41949) Print this report
Comment to Violin mode damping (41922)

We've found filters and gains that damp all modes. All violin mode (1st harmonics) are damped to under 2e-21 in strain, shown in Hrec here (and zoomed here).

41949_20180622190636_violindampingdeforeafterwhole.png

Since gain values may need to be changed, we've keep the config default values as zero; the working values are stored in the GUI code. After a recompile, you can press "SET ALL gains" to reset to these values. The current working settings are also attached here. We note that only WI requires 60 deg phase correction (use filter 2). We haven't checked to see if all WI modes damp better with this.

At max, we are driving 0.02 V per correction signal.

Images attached to this comment
Non-image files attached to this comment
Environmental Monitoring (Environmental Monitoring)
derossi, fiori, genin, hardwick, mantovani, michimura - 17:26 Friday 22 June 2018 (41947) Print this report
Tappings on IB W-flange and minilinks

In order to investigate for peaks at 101 Hz, 107 Hz, 157 Hz (41824) today we performed tappings in the area between IB and SIB2, including various spots along the B2 and RFC minilinks. We did it first with only RFC locked and ITF in recombined (INDEX = 82), then we repeated with SSFS locked (ITF index = 92). Figures 1 and 2 show the tapping locations in the first and second round respectively. We used the electronic hammer as a tool (but not acquired) and at some point (indicated below) we connected channel ENV_IB_BD_ACC_Z (usually connected to the PCB accelerometer on the W-flange beam dump) to one small accelerometer which we sticked in a few places (described below) and finally we left it sticked on the RFC flange (IB side) in horizontal direction.

Here the detailed time list:

***** tapping test in SIB2 room 22/06/2018 ****************
signals: Sc_MC_RFC_Err_Post (error signal for the IMC length lock, which in our case was using B4 (CARM error signal) and not RFC)


****************************************************************************************************************************************************************************************

******  recombined mode (PR misaligned, arms locked, carm to MC we use RFC error signal for the correction to the mode cleaner) ****
GPS given in LOCAL TIME
reference: 09:13:00
* is where we see well the 101Hz peak excited 
1)  09:22:05 --> 09:23:10		B2 minilink SIB2 side
2)  09:23:31 --> 09:24:15		B2 minilink middle
3)  09:24:50 --> 09:25:35		B2 minilink INJ tower side
4)  09:25:54 --> 09:26:27
5)  09:27:12 --> 09:27:34
6)  09:29:38 --> 09:30:04	*	flange
7)  09:31:13 --> 09:32:00	*	in the middle of the REF minilink 
8)  09:32:27 --> 09:32:59	*
9)  09:33:15 --> 09:34:02	*
10) 09:35:27 --> 09:36:05		lateral flange IB
11) 09:40:30 --> 09:40:48		small flange 
12) 09:41:17 --> 09:41:31
13) 09:41:32 --> 09:41:47
14) 09:42:14 --> 09:42:21
15) 09:42:35 --> 09:42:43
16) 09:42:50 --> 09:43:58
17) 09:43:50 --> 09:43:58
18) 09:44:04 --> 09:44:15
19) 09:44:30 --> ?		*
20) 09:44:45 --> 09:44:58	*
21) 09:45:41 --> 09:45:55
22) 09:54:03 --> 09:54:20		from inside SIB2, close to the window --> nothing
23) 09:54:48 --> 09:55:01 		same as 23

*** we put the accelerometer (ENV_IB_BD_ACC_Z) in the vertical direction on the RFC pipe (in the middle).
24) 10:31:34 --> 10:32:42  tapping on the minilink

****************************************************************************************************************************************************************************************

******** measurement with SSFS engaged ***********
new reference: 10:41:00

Signals: 
- Sc_MC_RFC_Err_Post (even if the RFC is unlocked it is still the signal to look at)
- ENV_IB_BD_ACC_X on the big flange, north side 
- ENV_IB_BD_ACC_Z on hte RFC minilink, along the beam direction

1)  10:43:24 --> 10:44:01	on the REF cavity minilink, close to INJ tower, along the beam direction
2)  unlock
3)  10:51:23 --> 10:52:03	"			"		      , along the vertical direction
4)  10:52:14 --> 10:52:39	on the B2 cavity minilink, close to INJ tower, along the beam direction
5)  10:52:51 --> 10:52:07
6)  10:53:17 --> 10:53:40	on the beam dump, along the beam direction
7)  10:53:52 --> 10:54:09	at the center of the flange
8)  10:54:19 --> 10:54:32	close to RFC pipe	*
9)  10:54:40 --> 10:54:49	closer to RFC pipe	*
10) 11:01:28 --> 11:01:50	RFC minilink, close to INJ tower, along the beam direction 
11) 11:02:50 --> 11:02:25	RFC minilink, in the middle, along the beam direction
12) 11:02:40 --> 11:03:08	RFC minilink, close to INJ tower, in the vertical direction
13) 11:03:22 --> 11:03:45	RFC minilinj, close to SIB2, on the beam direction
14) 11:03:54 --> 11:04:20	as 10
15) 11:08:35 --> 11:08:55
16) 11:10:24 --> 11:10:32 	tapping on the flange, next to RFC minilink, in the direction of the beam
17) 11:11:30 --> 11:11:40
18) 11:15:52 --> 11:16:05
19) 11:16:25 --> 11:16:45	side of the flange, next to the rfc minilink
20) 11:29:24 --> 11:29:59	on the side of the flange, transverse direction
Images attached to this report
AdV-COM (AdV commissioning (1st part) )
michimura, hardwick - 1:49 Friday 22 June 2018 (41935) Print this report
Comment to Line tracker now tracks violin modes and mirror bulk modes upto 44 kHz. (41883)

We had a quick look at the line tracker outputs, and confirmed that it is working well.
We found that DRUM1 and DRUM2 modes (likely to be of NI and WI) and BS DRUM and BUTTERFLY modes are kicked during the lock acquisition.
We also found that NE ring heater temperature changes by ~0.1 K between the locks.

Line tracker frequency outputs:
Frequency outputs from yesterday are attached. Some of them are noisy and they are maybe not from the mirror modes.

V1:PAY_{MIR}_VIOLIN#_FREQ (Good)
V1:PAY_BS_BUTTERFLY/DRUM_FREQ (Good)
V1:PAY_DRUM#_FREQ (3 at 7808.8Hz and 4 at 7808.9 Hz are too close and some times following two lines)
V1:PAY_9pt6kHz#_FREQ (1 at 9665.1 Hz and 2 at 9965.4 Hz are too close)
V1:PAY_10kHz#_FREQ (3 at 10112.0 Hz and 4 at 10112.2 Hz are too close)
V1:PAY_12kHz#_FREQ (some of them are noisy)
V1:PAY_15kHz#_FREQ (Good)
V1:PAY_26kHz#_FREQ (Good)
V1:PAY_39kHz#_FREQ (some of them are noisy)
V1:PAY_44kHz#_FREQ (some of them are noisy)


Some of DRUMs, 9pt6kHzs and 10kHzs have modes which are very close in frequency (see figures in logbook #41794), and the line tracker sometimes follows two peaks in the peak search range (see this figure).


Ring downs from lock acquisition and Q measurement:
Amplitude outputs of the line tracker are basicaly stable during the lock, but DRUM1 and DRUM2 modes and BS DRUM and BUTTERFLY modes have ringdowns during the lock. It looks like they are kicked during the lock acquisition.

We used this kick to derive the Q-values of the bulk modes. Using the 5 locks stretched for more than 1 hour of LOW_NOISE3 state in June 20, I got the following Q-values.

[BS]
DRUM      (1875.5 Hz): (6.2 +/- 0.1)e6  figure
BUTTERFLY (1256.5 Hz): (6.7 +/- 0.4)e6  figure

[Test masses]
DRUM1    (7804.5 Hz): (1.6 +/- 0.3)e7  figure
DRUM2    (7807.5 Hz): (8.2 +/- 0.4)e6  figure


Attached figures are the typical time series data for each mode used in the analysis. Variation between the measurements are also attached.
I used A*exp(-t/tau)+C for the fitting, and calculated Q-value using Q=pi*f0*tau, where f0 is the measured mode frequency (median of the line tracker frequency output during the lock).

The results look reasonable. See, also, measurements done using O2 data (VIR-0241A-18). They got Q>=2e6 from Lorentian fit of thermal peaks, and ~1e7 from ringdowns for test mass drum modes.

We note that there are some peaks which are not stable and also does not show clear ringdowns (for example, 44kHz1 often rings up and 44kHz2 often goes up and down).


Temperature dependence of drum modes:
We know that one of DRUM3 and DRUM4 is from WE from the drastic temperature change in WE (logbook #41794). We compared DRUM1/2 frequencies and ring heater temperatures, and found they both change along with the temperature change in NI and WI, but not NE and WE (see this figure; similar plot also in logbook #39767). NI and WI have a similar temperature change, so we cannot tell which is which at this point.
From the linear fit, mode frequency dependence on the temperature was derived to be 0.9 to 1.0 Hz/K, which is consistent with previous measurements (logbook #39039 and #41798).

Raw time series data used for the fit is also attached.
We noticed that NE ring heater temperature changes by ~0.1 K between the locks. Not as drastical as NE, but WE ring heater temperature also changes much, compared with WI and NI. This might indicate some scattering, point absorbers, cavity misalignment, etc.
Further investigations such as correlation between different temeprature sensors, alignment drift, etc is necessary.


Next:
 - Fit violin ringdowns and get Q-values (when violin damping is off !); we might see the effect from the ear damage?
 - Excitation tests to test if we can excite the bulk modes, identify which peaks belong to which mirrors, and measure Q-values.
 - Ring heater tests to identify the peaks, measure mode frequency temperature change, and measure the RoC change from transverse mode spacing measurement.
 - Look into NE (and WE) temperature change between the locks.
 - Look into the cause of the kicks during the lock acquisition.
 - Look into the peaks that are not very stable (and doesn't seem to be from the bulk modes)

 

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
hardwick, michimura, swinkels - 0:17 Thursday 21 June 2018 (41922) Print this report
Violin mode damping

Summary: Tonight we successfully implemented active violin mode damping. We demonstrated damping of modes on all test masses by length actuation on the marionettas. Modes that are isolated in frequency are easily damped into the noise floor. We had trouble with modes close together in frequency and on the same mirror, as expected; specifically around 449.3 Hz.

- - - - - - - -

Damping scheme

The damping scheme and associated channels are shown visually here. It goes as follows:

  1. take in DARM as error signal
  2. a BP filter is applied around violin mode: bandpass is 4th order buttorworth, ~200 mHz wide. There are two BP filters to chose from. Filter 1 is centered on measured violin frequency, Filter 2 is shifted by ~60 degrees
  3. apply gain to mode path
  4. all mode paths belonging to one mirror are summed together to create a mirror-specific correction signal
  5. correction signal is sent to either pitch or length of the marionetta

Damping notes

Gains and filters and drives that effectively damped are here. Times that damping started to occur are also there, in case anyone wants to look at data. All modes that are frequency-separated from other modes on same mirror were easily damped into the noise floor.

Ringdown activity here. Full before/after spectrum here. Bandpass coverage here. Note: we don't know what that broad bump in the spectrum is, but it's been there all night and we don't think its associated with our activity.

Only trouble modes are around 449.3 Hz. NE has modes at 449.30 and 449.33 Hz, making the sensing and independent damping difficult. We rang them up quite a bit before getting a setting that somewhat turned them around; they will need more work. Zoom in of spectrum around the modes here. Zoom of bandpass coverage mess here.

RMS channels are best indicators of damping/growing, but other nearby high modes can bleed in.

GUI

Yuta made an awesome GUI for violin mode damping, shown here!

For everything you can:

  • turn on/off a master switch. This is turned off by Metatron in the DOWN state, requires manual turn on (has 10 second ramp). In this way you can keep known good filters and gains set and eventually this can be turned on via Metatron.

For each mirror you can:

  • turn off the output
  • toggle between length/pitch marionetta drive
  • open relevant dataDisplay screens, which will start automatically.

For each mode you can:

  • get the current gain (wait time >5 sec)
  • set the gain
  • toggle between filter 1 & 2
  • emergency stop sending any signal along that mode path

GUI and associated config files are found in  /virgoDev/Automation/scripts/LSC/ViolinDamping/violingui.py. It can be opened for all mirrors ( >>python violingui.py ) and also for one mirror, input as an argument ( >>python violingui.py NE )

Other stuff

Violin damping infrustructure is in LSC_Acl.cfg, filters in LSC_Filters.cfg. Note: we hijacked ASC_{mirror}_TX/TY_NOISE_OUT channels to send to DSP for now. This will be cleaned up some, matrix options for drive, etc.

Average elapsed time of LSC_Acl increased form 12.8 to 16.6 us with all added filters, etc. We plan to next optimize some filters, etc., to bring this down.

Images attached to this report
Non-image files attached to this report
Comments to this report:
hardwick, michimura - 19:11 Friday 22 June 2018 (41949) Print this report

We've found filters and gains that damp all modes. All violin mode (1st harmonics) are damped to under 2e-21 in strain, shown in Hrec here (and zoomed here).

41949_20180622190636_violindampingdeforeafterwhole.png

Since gain values may need to be changed, we've keep the config default values as zero; the working values are stored in the GUI code. After a recompile, you can press "SET ALL gains" to reset to these values. The current working settings are also attached here. We note that only WI requires 60 deg phase correction (use filter 2). We haven't checked to see if all WI modes damp better with this.

At max, we are driving 0.02 V per correction signal.

Images attached to this comment
Non-image files attached to this comment
carbognani, michimura - 16:59 Tuesday 26 June 2018 (41997) Print this report
The violin mode damping GUI has been packaged as violinUI separate package and a production version (v1r1) has been uploaded in /virgoApp:
/virgoApp/violinUI/v1r1

This version has also been added under the IceWM menu SUS section and all declinations of the GUI can be started from there (Fig. 1)
Images attached to this comment
michimura - 14:07 Monday 06 August 2018 (42344) Print this report

I made a PyQt version of GUI for violing damping.
Previously, the GUI was made with Python Tkinter and current values are acquired using AclParamGet commants.
PyQt version uses ConnectOnline function to continuously get the current values (see logbook #42150 and comments).

PyQt version has almost the same functionality as before, but better since you can monitor the current values live and easier to understand the signal flow.
To save which filters are used and to save whether TX or TY is used, I added the following lines to LSC_SMS.cfg (this is the reason I had to restart LSC Acl; see logbook #42298).

ACL_SMS        "LSC_"        NI_VIOLIN1_ERR    NI_VIOLIN2_ERR    NI_VIOLIN3_ERR    NI_VIOLIN4_ERR    NI_VIOLIN5_ERR    NI_VIOLIN6_ERR    NI_VIOLIN7_ERR    NI_VIOLIN8_ERR
ACL_SMS        "LSC_"        NE_VIOLIN1_ERR    NE_VIOLIN2_ERR    NE_VIOLIN3_ERR    NE_VIOLIN4_ERR    NE_VIOLIN5_ERR    NE_VIOLIN6_ERR    NE_VIOLIN7_ERR    NE_VIOLIN8_ERR
ACL_SMS        "LSC_"        WI_VIOLIN1_ERR    WI_VIOLIN2_ERR    WI_VIOLIN3_ERR    WI_VIOLIN4_ERR    WI_VIOLIN5_ERR    WI_VIOLIN6_ERR    WI_VIOLIN7_ERR    WI_VIOLIN8_ERR
ACL_SMS        "LSC_"        WE_VIOLIN1_ERR    WE_VIOLIN2_ERR    WE_VIOLIN3_ERR    WE_VIOLIN4_ERR    WE_VIOLIN5_ERR    WE_VIOLIN6_ERR    WE_VIOLIN7_ERR    WE_VIOLIN8_ERR
ACL_SMS        "LSC_"        ASC_NI_TX_NOISE_CORR    ASC_NE_TX_NOISE_CORR    ASC_WI_TX_NOISE_CORR    ASC_WE_TX_NOISE_CORR
ACL_SMS        "LSC_"        ASC_NI_TY_NOISE_CORR    ASC_NE_TY_NOISE_CORR    ASC_WI_TY_NOISE_CORR    ASC_WE_TY_NOISE_CORR


"Restore Defaults" button on the top right will restore saved values of GAINs and filters and applies them.
Attached figure shows the current default GAINs and filters which were used in June 22 (at 13W; logbook #41949).

Images attached to this comment
AdV-COM (AdV commissioning (1st part) )
hardwick, michimura - 21:13 Tuesday 19 June 2018 (41905) Print this report
Comment to Further violin mode excitations: WI,NE,WE (41775)

I've had a second look, including at the NI kick time (~June 5 20:00 UTC) and I attach an updated, more sure violin mode list. The only changes were to input modes. Yuta has updated the line tracker code accordingly.

Non-image files attached to this comment
AdV-COM (AdV commissioning (1st part) )
michimura, hardwick, swinkels - 22:28 Monday 18 June 2018 (41885) Print this report
Line tracker now tracks violin modes and mirror bulk modes upto 44 kHz.

Additional note to logbook #41883 (I posted twice, sorry)

The edge frequencies (boundary frequencies) to search for the peak are basically placed at the center of the neibouring line frequencies, but if the neibouring line frequencies are too far from each other, the edges are placed 1 Hz away from the measured line frequency. 1 Hz should be large enough to track the mode frequency shifts during the ring heater test (logbook #39679 gives ~0.1 Hz drum mode frequency shift with ~0.5 deg ring heater temperature rise), and should be small enough to avoid tracking other peaks (see attached figures in logbook #41794).

AdV-COM (AdV commissioning (1st part) )
michimura, hardwick, swinkels - 22:25 Monday 18 June 2018 (41884) Print this report
Line tracker now tracks violin modes and mirror bulk modes upto 44 kHz.

We have fixed some bugs in the line tracker code associated with multiple demodulation frequencies and added more modes to track.
We hsve also changed the channel to demodulate from 20 kHz sampled SDB2_B1_PDA2_Audio to 100 kHz sampled SDB2_B1_PDA2_Audio_100k to track bulk modes at higher frequencies.
The code lives in /virgoDev/Automation/PyALP/PySpectral/algo.py
The edge frequencies (boundary frequencies) to search for the peak are basically placed at the center of the neibouring line frequencies, but if the neibouring line frequencies are too far from each other, the edges are placed 1 Hz away from the measured line frequency. 1 Hz should be large enough to track the mode frequency shifts during the ring heater test (logbook #39679 gives ~0.1 Hz drum mode frequency shift with ~0.5 deg ring heater temperature rise), and should be small enough to avoid tracking other peaks (see attached figures in logbook #41794).

Attached are the full list of channels added, their demodulation frequencies and measured line frequencies (logbook #41842, #41794, #41807, #41815).
There are 83 lines tracked in total nowdevil

V1:PAY_{MIR}_VIOLIN# (XX are the ones we are not sure)
V1:PAY_BS_BUTTERFLY
V1:PAY_BS_DRUM
V1:PAY_DRUM#
V1:PAY_9pt6kHz#
V1:PAY_10kHz#
V1:PAY_12kHz#
V1:PAY_15kHz#
V1:PAY_26kHz#
V1:PAY_39kHz#
V1:PAY_44kHz#

AdV-COM (AdV commissioning (1st part) )
michimura, hardwick, swinkels - 21:33 Monday 18 June 2018 (41883) Print this report
Line tracker now tracks violin modes and mirror bulk modes upto 44 kHz.

We have fixed some bugs in the line tracker code associated with multiple demodulation frequencies and added more modes to track.
We hsve also changed the channel to demodulate from 20 kHz sampled SDB2_B1_PDA2_Audio to 100 kHz sampled SDB2_B1_PDA2_Audio_100k to track bulk modes at higher frequencies.
The code lives in /virgoDev/Automation/PyALP/PySpectral/algo.py

Attached are the full list of channels added, their demodulation frequencies and measured line frequencies (logbook #41842, #41794, #41807, #41815).
There are 83 lines tracked in total nowdevil

V1:PAY_{MIR}_VIOLIN# (XX are the ones we are not sure)
V1:PAY_BS_BUTTERFLY
V1:PAY_BS_DRUM
V1:PAY_DRUM#
V1:PAY_9pt6kHz#
V1:PAY_10kHz#
V1:PAY_12kHz#
V1:PAY_15kHz#
V1:PAY_26kHz#
V1:PAY_39kHz#
V1:PAY_44kHz#

Non-image files attached to this report
Comments to this report:
michimura, hardwick - 1:49 Friday 22 June 2018 (41935) Print this report

We had a quick look at the line tracker outputs, and confirmed that it is working well.
We found that DRUM1 and DRUM2 modes (likely to be of NI and WI) and BS DRUM and BUTTERFLY modes are kicked during the lock acquisition.
We also found that NE ring heater temperature changes by ~0.1 K between the locks.

Line tracker frequency outputs:
Frequency outputs from yesterday are attached. Some of them are noisy and they are maybe not from the mirror modes.

V1:PAY_{MIR}_VIOLIN#_FREQ (Good)
V1:PAY_BS_BUTTERFLY/DRUM_FREQ (Good)
V1:PAY_DRUM#_FREQ (3 at 7808.8Hz and 4 at 7808.9 Hz are too close and some times following two lines)
V1:PAY_9pt6kHz#_FREQ (1 at 9665.1 Hz and 2 at 9965.4 Hz are too close)
V1:PAY_10kHz#_FREQ (3 at 10112.0 Hz and 4 at 10112.2 Hz are too close)
V1:PAY_12kHz#_FREQ (some of them are noisy)
V1:PAY_15kHz#_FREQ (Good)
V1:PAY_26kHz#_FREQ (Good)
V1:PAY_39kHz#_FREQ (some of them are noisy)
V1:PAY_44kHz#_FREQ (some of them are noisy)


Some of DRUMs, 9pt6kHzs and 10kHzs have modes which are very close in frequency (see figures in logbook #41794), and the line tracker sometimes follows two peaks in the peak search range (see this figure).


Ring downs from lock acquisition and Q measurement:
Amplitude outputs of the line tracker are basicaly stable during the lock, but DRUM1 and DRUM2 modes and BS DRUM and BUTTERFLY modes have ringdowns during the lock. It looks like they are kicked during the lock acquisition.

We used this kick to derive the Q-values of the bulk modes. Using the 5 locks stretched for more than 1 hour of LOW_NOISE3 state in June 20, I got the following Q-values.

[BS]
DRUM      (1875.5 Hz): (6.2 +/- 0.1)e6  figure
BUTTERFLY (1256.5 Hz): (6.7 +/- 0.4)e6  figure

[Test masses]
DRUM1    (7804.5 Hz): (1.6 +/- 0.3)e7  figure
DRUM2    (7807.5 Hz): (8.2 +/- 0.4)e6  figure


Attached figures are the typical time series data for each mode used in the analysis. Variation between the measurements are also attached.
I used A*exp(-t/tau)+C for the fitting, and calculated Q-value using Q=pi*f0*tau, where f0 is the measured mode frequency (median of the line tracker frequency output during the lock).

The results look reasonable. See, also, measurements done using O2 data (VIR-0241A-18). They got Q>=2e6 from Lorentian fit of thermal peaks, and ~1e7 from ringdowns for test mass drum modes.

We note that there are some peaks which are not stable and also does not show clear ringdowns (for example, 44kHz1 often rings up and 44kHz2 often goes up and down).


Temperature dependence of drum modes:
We know that one of DRUM3 and DRUM4 is from WE from the drastic temperature change in WE (logbook #41794). We compared DRUM1/2 frequencies and ring heater temperatures, and found they both change along with the temperature change in NI and WI, but not NE and WE (see this figure; similar plot also in logbook #39767). NI and WI have a similar temperature change, so we cannot tell which is which at this point.
From the linear fit, mode frequency dependence on the temperature was derived to be 0.9 to 1.0 Hz/K, which is consistent with previous measurements (logbook #39039 and #41798).

Raw time series data used for the fit is also attached.
We noticed that NE ring heater temperature changes by ~0.1 K between the locks. Not as drastical as NE, but WE ring heater temperature also changes much, compared with WI and NI. This might indicate some scattering, point absorbers, cavity misalignment, etc.
Further investigations such as correlation between different temeprature sensors, alignment drift, etc is necessary.


Next:
 - Fit violin ringdowns and get Q-values (when violin damping is off !); we might see the effect from the ear damage?
 - Excitation tests to test if we can excite the bulk modes, identify which peaks belong to which mirrors, and measure Q-values.
 - Ring heater tests to identify the peaks, measure mode frequency temperature change, and measure the RoC change from transverse mode spacing measurement.
 - Look into NE (and WE) temperature change between the locks.
 - Look into the cause of the kicks during the lock acquisition.
 - Look into the peaks that are not very stable (and doesn't seem to be from the bulk modes)

 

Images attached to this comment
hardwick - 12:55 Friday 29 June 2018 (42028) Print this report

As noted previously, the NE ring heater temperature sensors see larger temperature changes with lock/locklosses. To check if this is just a RH TE calibration error, I looked at the vertical drift (the blade springs sag or stiffen with temperature and thus are a best true change-of-temperature sensor). Daily ambient temperatures dominate, so I roughly subtracted this by finding lockloss during a mostly linear vertical drift time and detrending linearly. The residual confirms what the ring heater temp sensors see: NE tower sees ~2x temperature change compared to WE during lock/lockloss. The attached plot shows the end ring heater temp sensors, the linear fit on the raw vertical data (I use vertical sensors above the marionetta and in payload chamber), and the detrended vertical data. I looked also since the power increase, but we've had few locks; it looks comparable now at 25W but the ambient temp looks less linear in the lock times, making simple linear detrend less reliable. Should be investigated more with cleaner data/better subtraction. Script is in /users/hardwick/scripts/mirror_temp.py. Just need to change time and duration.

I also looked again at the west end during the large temp change when the air conditioning went off; shown here. We can roughly calibrate: 0.36 RH degC / 1 WEB degC and 235 um Vert / 1 WEB degC. Note this doesnt take into account the lock which held for the beginning part of the large ambient temp change.

Images attached to this comment
Search Help
×

Warning

×